This simple tutorial takes the solution from EJB3 Tutorial 5 - Message Driven Beans and augments the beans with the configuration information necessary to limit access declaratively.
Project Setup
We recommend you create a copy of your project (or if you are using revision control software, make sure to check-in and tag your work).
We need to create a few basic files: users.properties and roles.properties.
This file defines user accounts. Note that while the use of this information is defined in the specification, exactly how it is configured is vendor specific.
This file should reside anywhere in the root of a classpath entry. Place this in the conf directory, which is configured as a source entry.
By the way, notice that it is users and not user. You can use another name, but this is the default name JBoss uses.
Next we need to configure the bean with security information. As usual, we can use either XML or annotations. Here is an updated version of AccountInventoryBean.java:
AccountInventoryBean.java
packagesession;importjava.util.Calendar;importjava.util.List;importjavax.annotation.security.PermitAll;importjavax.annotation.security.RolesAllowed;importjavax.ejb.Stateless;importjavax.persistence.EntityManager;importjavax.persistence.PersistenceContext;importorg.jboss.annotation.security.SecurityDomain;importentity.Account;importentity.Charge;importentity.TollTag;/**
* SecurityDomain is a JBoss extension that allows you to describe which
* security domain to use. The security domain defines how validation is
* performed. The "other" security domain, which is provided by default, simply
* uses two files: users.properties and roles.properties for security
* configuration. You can also store this information in a database or build a
* bridge to your implementation. This is outside the scope of the
* specification.
*/
@Stateless
@SecurityDomain("other")publicclass AccountInventoryBean implements AccountInventory {
@PersistenceContext(unitName = "tolltag")private EntityManager em;public EntityManager getEm(){return em;}/**
* Only allow users that can play the role of admin to access this method.
*/
@RolesAllowed({"admin"})publicvoid createAccount(final Account account){
getEm().persist(account);}
@RolesAllowed({"admin", "user"})public Account findAccountById(finalLong id){return getEm().find(Account.class, id);}/**
* The default access is PermitAll if you do not otherwise specify the roles
* allowed. You can change this default by applying the RolesAllowed
* annotation to the class instead of a method.
*/
@PermitAll
publicvoid removeTag(finalString tagNumber){final TollTag tt = (TollTag) getEm().createNamedQuery("TollTag.byTollTagNumber").setParameter("tagNumber", tagNumber)
.getSingleResult();final Account account = tt.getAccount();
account.removeTollTag(tt);
tt.setAccount(null);
getEm().remove(tt);
getEm().flush();}publicvoid removeAccountById(finalLong id){final Account toRemove = findAccountById(id);
getEm().remove(toRemove);
getEm().flush();}// ... the rest is unchanged}
and the updated interface:
AccountInventory.java
packagesession;importjavax.ejb.Local;importentity.Account;/**
* This interface is a bit abnormal as it is being used for both a stateful and
* stateless session bean. See individual method comments for clarification.
*/
@Local
publicinterface AccountInventory {void removeAccountById(long id);// . . . the rest is unchanged}
Updated JBossUtil
We now need to update JBossUtil once more to read our security properties. The only method that has changed is startDeployer:
This method now reads in MDB configuration information in the first two calls to deployXmlResources and configures the security settings in the third line.
The Test
This test attempts one successful and four failed attempts. The names of the methods describe whether we expect success or failure: AccountInventoryBeanTest.java
Notice that in all cases where the method is expected to generate an exception, we first catch EJBAccessException. EJBAccessException is a wrapper exception. We verify the contents by getting the wrapped exception and throwing it. We then let JUnit tell us if we got the exception we expected.
Questions
If you do not provide a RolesAllowed, what is the default?
How do you set a different default value for all the methods in a class?
Table of Contents
Ejb3 Tutorial 6 - Security
This simple tutorial takes the solution from EJB3 Tutorial 5 - Message Driven Beans and augments the beans with the configuration information necessary to limit access declaratively.Project Setup
We recommend you create a copy of your project (or if you are using revision control software, make sure to check-in and tag your work).We need to create a few basic files: users.properties and roles.properties.
users.properties
This file defines user accounts. Note that while the use of this information is defined in the specification, exactly how it is configured is vendor specific.
This file should reside anywhere in the root of a classpath entry. Place this in the conf directory, which is configured as a source entry.
By the way, notice that it is users and not user. You can use another name, but this is the default name JBoss uses.
roles.properties
The comments from users.properties apply here.
Update Session Bean
Next we need to configure the bean with security information. As usual, we can use either XML or annotations. Here is an updated version of AccountInventoryBean.java:AccountInventoryBean.java
and the updated interface:
AccountInventory.java
Updated JBossUtil
We now need to update JBossUtil once more to read our security properties. The only method that has changed is startDeployer:This method now reads in MDB configuration information in the first two calls to deployXmlResources and configures the security settings in the third line.
The Test
This test attempts one successful and four failed attempts. The names of the methods describe whether we expect success or failure:AccountInventoryBeanTest.java
Notice that in all cases where the method is expected to generate an exception, we first catch EJBAccessException. EJBAccessException is a wrapper exception. We verify the contents by getting the wrapped exception and throwing it. We then let JUnit tell us if we got the exception we expected.
Questions
If you do not provide a RolesAllowed, what is the default?How do you set a different default value for all the methods in a class?
<--Back